Binding Host WebAssembly: Integrazione Perfetta con l'Ambiente di Runtime

WebAssembly (WASM) si è evoluto rapidamente da una tecnologia esclusiva per browser a una soluzione di runtime universale. La sua promessa di alte prestazioni, portabilità e sicurezza lo rende una scelta attraente per una vasta gamma di applicazioni, dalle funzioni serverless ai sistemi embedded. Tuttavia, affinché WASM possa sbloccare veramente il suo potenziale, deve interagire in modo trasparente con l'ambiente host, ovvero il programma o il sistema che esegue il modulo WASM. È qui che i Binding Host WebAssembly svolgono un ruolo cruciale.

In questa guida completa, approfondiremo le complessità dei binding host WebAssembly, esplorando cosa sono, perché sono essenziali e come consentono un'integrazione robusta tra i moduli WASM e i loro diversi ambienti di runtime. Esamineremo vari approcci, metteremo in evidenza casi d'uso reali e forniremo spunti pratici per gli sviluppatori che desiderano sfruttare questa potente funzionalità.

Comprendere i Binding Host WebAssembly

Nella sua essenza, WebAssembly è progettato come un target di compilazione portabile per i linguaggi di programmazione. I moduli WASM sono essenzialmente unità di codice autonome che possono essere eseguite in un ambiente sandboxed. Questa sandbox fornisce sicurezza per impostazione predefinita, limitando ciò che il codice WASM può fare. Tuttavia, la maggior parte delle applicazioni pratiche richiede che i moduli WASM interagiscano con il mondo esterno – per accedere alle risorse di sistema, comunicare con altre parti dell'applicazione o sfruttare librerie esistenti.

I binding host, noti anche come funzioni importate o funzioni host, sono il meccanismo attraverso il quale un modulo WASM può chiamare funzioni definite e fornite dall'ambiente host. Pensatelo come un contratto: il modulo WASM dichiara di aver bisogno che determinate funzioni siano disponibili e l'ambiente host ne garantisce la fornitura.

Allo stesso modo, l'ambiente host può anche invocare funzioni esportate da un modulo WASM. Questa comunicazione bidirezionale è fondamentale per qualsiasi integrazione significativa.

Perché i Binding Host sono Essenziali?

• Interoperabilità: I binding host sono il ponte che consente al codice WASM di interoperare con il linguaggio host e il suo ecosistema. Senza di essi, i moduli WASM sarebbero isolati e incapaci di eseguire compiti comuni come leggere file, effettuare richieste di rete o interagire con interfacce utente.
• Sfruttare Funzionalità Esistenti: Gli sviluppatori possono scrivere la loro logica di base in WASM (magari per motivi di prestazioni o portabilità) sfruttando al contempo le vaste librerie e capacità del loro ambiente host (ad es. librerie C++, primitive di concorrenza di Go o la manipolazione del DOM di JavaScript).
• Sicurezza e Controllo: L'ambiente host detta quali funzioni sono esposte al modulo WASM. Ciò fornisce un controllo granulare sulle capacità concesse al codice WASM, migliorando la sicurezza esponendo solo le funzionalità necessarie.
• Ottimizzazioni delle Prestazioni: Per compiti computazionalmente intensivi, può essere molto vantaggioso delegarli a WASM. Tuttavia, questi compiti spesso devono interagire con l'host per I/O o altre operazioni. I binding host facilitano questo scambio efficiente di dati e la delega di compiti.
• Portabilità: Sebbene WASM sia di per sé portabile, il modo in cui interagisce con l'ambiente host può variare. Interfacce di binding host ben progettate mirano ad astrarre questi dettagli specifici dell'host, consentendo ai moduli WASM di essere riutilizzati più facilmente in diversi ambienti di runtime.

Pattern e Approcci Comuni per i Binding Host

L'implementazione dei binding host può variare a seconda del runtime WebAssembly e dei linguaggi coinvolti. Tuttavia, sono emersi diversi pattern comuni:

1. Importazioni Esplicite di Funzioni

Questo è l'approccio più fondamentale. Il modulo WASM elenca esplicitamente le funzioni che si aspetta di importare dall'host. L'ambiente host fornisce quindi le implementazioni per queste funzioni importate.

Esempio: Un modulo WASM scritto in Rust potrebbe importare una funzione come console_log(message: *const u8, len: usize) dall'host. L'ambiente host JavaScript fornirebbe quindi una funzione chiamata console_log che accetta un puntatore e una lunghezza, dereferenzia la memoria a quell'indirizzo e chiama il console.log di JavaScript.

Aspetti chiave:

• Sicurezza dei Tipi (Type Safety): La firma della funzione importata (nome, tipi di argomenti, tipi di ritorno) deve corrispondere all'implementazione dell'host.
• Gestione della Memoria: I dati passati tra il modulo WASM e l'host risiedono spesso nella memoria lineare del modulo WASM. I binding devono gestire la lettura e la scrittura in questa memoria in modo sicuro.

2. Chiamate Indirette di Funzioni (Puntatori a Funzione)

Oltre alle importazioni dirette di funzioni, WASM consente all'host di passare puntatori (o riferimenti) a funzioni come argomenti alle funzioni WASM. Ciò consente al codice WASM di invocare dinamicamente funzioni fornite dall'host a runtime.

Esempio: Un modulo WASM potrebbe ricevere un puntatore a una funzione di callback per la gestione degli eventi. Quando un evento si verifica all'interno del modulo WASM, può invocare questa callback, passando i dati pertinenti all'host.

Aspetti chiave:

• Flessibilità: Consente interazioni più dinamiche e complesse rispetto alle importazioni dirette.
• Overhead: A volte può introdurre un leggero overhead prestazionale rispetto alle chiamate dirette.

3. WASI (WebAssembly System Interface)

WASI è un'interfaccia di sistema modulare per WebAssembly, progettata per consentire a WASM di funzionare al di fuori del browser in modo sicuro e portabile. Definisce un insieme standardizzato di API che i moduli WASM possono importare, coprendo funzionalità di sistema comuni come I/O di file, networking, orologi e generazione di numeri casuali.

Esempio: Invece di importare funzioni personalizzate per la lettura di file, un modulo WASM può importare funzioni come fd_read o path_open dal modulo wasi_snapshot_preview1. Il runtime WASM fornisce quindi l'implementazione per queste funzioni WASI, spesso traducendole in chiamate di sistema native.

Aspetti chiave:

• Standardizzazione: Mira a fornire un'API coerente tra diversi runtime WASM e ambienti host.
• Sicurezza: WASI è progettato tenendo conto della sicurezza e del controllo degli accessi basato sulle capacità.
• Ecosistema in Evoluzione: WASI è ancora in fase di sviluppo attivo, con nuovi moduli e funzionalità in aggiunta.

4. API e Librerie Specifiche del Runtime

Molti runtime WebAssembly (come Wasmtime, Wasmer, WAMR, Wazero) forniscono le proprie API e librerie di livello superiore per semplificare la creazione e la gestione dei binding host. Queste spesso astraggono i dettagli di basso livello della gestione della memoria WASM e della corrispondenza delle firme delle funzioni.

Esempio: Uno sviluppatore Rust che utilizza la crate wasmtime può usare gli attributi #[wasmtime_rust::async_trait] e #[wasmtime_rust::component] per definire funzioni host e componenti con un minimo di codice boilerplate. Allo stesso modo, wasmer-sdk in Rust o `wasmer-interface-types` in vari linguaggi forniscono strumenti per definire interfacce e generare binding.

Aspetti chiave:

• Esperienza dello Sviluppatore: Migliora significativamente la facilità d'uso e riduce la probabilità di errori.
• Efficienza: Spesso ottimizzati per le prestazioni all'interno del loro specifico runtime.
• Vendor Lock-in: Potrebbe legare la vostra implementazione più strettamente a un particolare runtime.

Integrare WASM con Diversi Ambienti Host

La potenza dei binding host WebAssembly è più evidente quando consideriamo come WASM può integrarsi con vari ambienti host. Esploriamo alcuni esempi di spicco:

1. Browser Web (JavaScript come Host)

Questo è il luogo di nascita di WebAssembly. Nel browser, JavaScript agisce come host. I moduli WASM vengono caricati e istanziati utilizzando l'API JavaScript di WebAssembly.

• Binding: JavaScript fornisce funzioni importate al modulo WASM. Questo viene spesso fatto creando un oggetto WebAssembly.Imports.
• Scambio di Dati: I moduli WASM hanno la loro memoria lineare. JavaScript può accedere a questa memoria utilizzando oggetti WebAssembly.Memory per leggere/scrivere dati. Librerie come wasm-bindgen automatizzano il complesso processo di passaggio di tipi di dati complessi (stringhe, oggetti, array) tra JavaScript e WASM.
• Casi d'Uso: Sviluppo di giochi (Unity, Godot), elaborazione multimediale, compiti computazionalmente intensivi in applicazioni web, sostituzione di moduli JavaScript critici per le prestazioni.

Esempio Globale: Consideriamo un'applicazione web di fotoritocco. Un algoritmo di filtraggio delle immagini computazionalmente intensivo potrebbe essere scritto in C++ e compilato in WASM. JavaScript caricherebbe il modulo WASM, fornirebbe una funzione host process_image che accetta i dati dell'immagine (magari come un array di byte nella memoria WASM), e quindi mostrerebbe l'immagine elaborata all'utente.

2. Runtime Server-Side (es. Node.js, Deno)

Eseguire WASM al di fuori del browser apre un vasto nuovo panorama. Node.js e Deno sono popolari runtime JavaScript che possono ospitare moduli WASM.

• Binding: Similmente agli ambienti browser, JavaScript in Node.js o Deno può fornire funzioni importate. I runtime hanno spesso supporto integrato o moduli per caricare e interagire con WASM.
• Accesso alle Risorse di Sistema: Ai moduli WASM ospitati sul server può essere concesso l'accesso al file system dell'host, ai socket di rete e ad altre risorse di sistema tramite binding host attentamente realizzati. WASI è particolarmente rilevante in questo contesto.
• Casi d'Uso: Estendere Node.js con moduli ad alte prestazioni, eseguire codice non attendibile in modo sicuro, implementazioni di edge computing, microservizi.

Esempio Globale: Una piattaforma di e-commerce globale potrebbe utilizzare Node.js per il suo backend. Per gestire l'elaborazione dei pagamenti in modo sicuro ed efficiente, un modulo critico potrebbe essere scritto in Rust e compilato in WASM. Questo modulo WASM importerebbe funzioni da Node.js per interagire con un modulo di sicurezza hardware (HSM) sicuro o per eseguire operazioni crittografiche, garantendo che i dati sensibili non lascino mai la sandbox WASM o vengano gestiti da funzioni host fidate.

3. Applicazioni Native (es. C++, Go, Rust)

I runtime WebAssembly come Wasmtime e Wasmer sono integrabili in applicazioni native scritte in linguaggi come C++, Go e Rust. Ciò consente agli sviluppatori di integrare moduli WASM in applicazioni C++ esistenti, servizi Go o demoni Rust.

• Binding: Il linguaggio di embedding fornisce le funzioni host. I runtime offrono API per definire queste funzioni e passarle all'istanza WASM.
• Scambio di Dati: Meccanismi efficienti di trasferimento dati sono cruciali. I runtime forniscono modi per mappare la memoria WASM e chiamare funzioni WASM dal linguaggio host, e viceversa.
• Casi d'Uso: Sistemi di plugin, sandboxing di codice non attendibile all'interno di un'applicazione nativa, esecuzione di codice scritto in un linguaggio all'interno di un'applicazione scritta in un altro, piattaforme serverless, dispositivi embedded.

Esempio Globale: Una grande multinazionale che sviluppa una nuova piattaforma IoT potrebbe utilizzare un sistema Linux embedded basato su Rust. Potrebbero usare WebAssembly per distribuire e aggiornare la logica sui dispositivi edge. L'applicazione Rust principale agirebbe come host, fornendo binding host a moduli WASM (compilati da vari linguaggi come Python o Lua) per l'elaborazione dei dati dei sensori, il controllo dei dispositivi e il processo decisionale locale. Ciò consente flessibilità nella scelta del miglior linguaggio per compiti specifici del dispositivo, mantenendo al contempo un runtime sicuro e aggiornabile.

4. Serverless ed Edge Computing

Le piattaforme serverless e gli ambienti di edge computing sono candidati ideali per WebAssembly grazie ai suoi tempi di avvio rapidi, al suo ingombro ridotto e al suo isolamento di sicurezza.

• Binding: Le piattaforme serverless forniscono tipicamente API per interagire con i loro servizi (es. database, code di messaggi, autenticazione). Queste sono esposte come funzioni WASM importate. WASI è spesso il meccanismo sottostante per queste integrazioni.
• Casi d'Uso: Esecuzione di logica di backend senza gestire server, funzioni edge per l'elaborazione di dati a bassa latenza, logica di content delivery network (CDN), gestione di dispositivi IoT.

Esempio Globale: Un servizio di streaming globale potrebbe utilizzare funzioni basate su WASM all'edge per personalizzare le raccomandazioni di contenuti in base alla posizione dell'utente e alla cronologia di visualizzazione. Queste funzioni edge, ospitate su server CDN in tutto il mondo, importerebbero binding per accedere ai dati utente memorizzati nella cache e interagire con un'API del motore di raccomandazione, il tutto beneficiando degli avvii a freddo rapidi e dell'utilizzo minimo di risorse di WASM.

Implementazione Pratica: Casi di Studio ed Esempi

Vediamo come i binding host vengono implementati praticamente utilizzando runtime e combinazioni di linguaggi popolari.

Caso di Studio 1: Modulo WASM in Rust che Chiama Funzioni JavaScript

Questo è uno scenario comune per lo sviluppo web. La toolchain wasm-bindgen è fondamentale in questo caso.

Codice Rust (nel tuo file `.rs`):

            
// Declare the function we expect from JavaScript
#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

            

              
                Copy
              
            
          

Codice JavaScript (nel tuo file HTML o `.js`):

            
// Import the WASM module
import init, { greet } from './pkg/my_wasm_module.js';

async function run() {
  await init(); // Initialize WASM module
  greet("World"); // Call the exported WASM function
}

run();

            

              
                Copy
              
            
          

Spiegazione:

• Il blocco `extern "C"` in Rust dichiara le funzioni che saranno importate dall'host. #[wasm_bindgen] viene utilizzato per contrassegnare queste e altre funzioni per un'interoperabilità trasparente.
• wasm-bindgen genera il codice collante (glue code) JavaScript necessario e gestisce il complesso marshalling dei dati tra Rust (compilato in WASM) e JavaScript.

Caso di Studio 2: Applicazione Go che Ospita un Modulo WASM con WASI

Utilizzando il pacchetto Go wasi_ext (o simile) con un runtime WASM come Wasmtime.

Codice Host Go:

            
package main

import (
    "fmt"
    "os"

    "github.com/bytecodealliance/wasmtime-go"
)

func main() {
    // Create a new runtime linker
    linker := wasmtime.NewLinker(wasmtime.NewStore(nil))

    // Define WASI preview1 capabilities (e.g., stdio, clocks)
    wasiConfig := wasmtime.NewWasiConfig()
    wasiConfig.SetStdout(os.Stdout)
    wasiConfig.SetStderr(os.Stderr)

    // Create a WASI instance bound to the linker
    wasi, _ := wasmtime.NewWasi(linker, wasiConfig)

    // Load WASM module from file
    module, _ := wasmtime.NewModuleFromFile(linker.GetStore(), "my_module.wasm")

    // Instantiate the WASM module
    instance, _ := linker.Instantiate(module)

    // Get the WASI export (usually `_start` or `main`)
    // The actual entry point depends on how the WASM was compiled
    entryPoint, _ := instance.GetFunc("my_entry_point") // Example entry point

    // Call the WASM entry point
    if entryPoint != nil {
        entryPoint.Call()
    } else {
        fmt.Println("Entry point function not found.")
    }

    // Clean up WASI resources
    wasi.Close()
}

            

              
                Copy
              
            
          

Modulo WASM (es. compilato da C/Rust con target WASI):

Il modulo WASM utilizzerebbe semplicemente chiamate WASI standard, come la stampa su standard output:

            
// Example in C compiled with --target=wasm32-wasi
#include <stdio.h>

int main() {
    printf("Hello from WebAssembly WASI module!\n");
    return 0;
}

            

              
                Copy
              
            
          

Spiegazione:

• L'host Go crea uno store e un linker Wasmtime.
• Configura le capacità WASI, mappando l'output/errore standard ai descrittori di file di Go.
• Il modulo WASM viene caricato e istanziato, con le funzioni WASI importate e fornite dal linker.
• Il programma Go chiama quindi una funzione esportata all'interno del modulo WASM, che a sua volta utilizza funzioni WASI (come fd_write) per produrre output.

Caso di Studio 3: Applicazione C++ che Ospita WASM con Binding Personalizzati

Utilizzando un runtime come Wasmer-C-API o l'API C di Wasmtime.

Codice Host C++ (esempio concettuale con l'API C di Wasmer):

            
#include <wasmer.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Custom host function implementation
void my_host_log(int message_ptr, int message_len) {
    // Need to access WASM memory here to get the string
    // This requires managing the WASM instance's memory
    printf("[HOST LOG]: "
           "%.*s\n",
           message_len, // Assuming message_len is correct
           wasm_instance_memory_buffer(instance, message_ptr, message_len)); // Hypothetical memory access function
}

int main() {
    // Initialize Wasmer
    wasmer_engine_t* engine = wasmer_engine_new();
    wasmer_store_t* store = wasmer_store_new(engine);

    // Create a Wasmtime linker or Wasmer Imports object
    wasmer_imports_t* imports = wasmer_imports_new();

    // Define the host function signature
    wasmer_func_type_t* func_type = wasmer_func_type_new(
        (wasmer_value_kind_t[]) { WASMER_VALUE_I32 }, // Param 1: pointer (i32)
        1,
        (wasmer_value_kind_t[]) { WASMER_VALUE_I32 }, // Param 2: length (i32)
        1,
        (wasmer_value_kind_t[]) { WASMER_VALUE_VOID }, // Return type: void
        0
    );

    // Create a callable host function
    wasmer_func_t* host_func = wasmer_func_new(store, func_type, my_host_log);

    // Add the host function to the imports object
    wasmer_imports_define(imports, "env", "log", host_func);

    // Compile and instantiate the WASM module
    wasmer_module_t* module = NULL;
    wasmer_instance_t* instance = NULL;
    // ... load "my_module.wasm" ...
    // ... instantiate instance using store and imports ...

    // Get and call an exported WASM function
    wasmer_export_t* export = wasmer_instance_exports_get_index(instance, 0); // Assuming first export is our target
    wasmer_value_t* result = NULL;
    wasmer_call(export->func, &result);

    // ... handle result and clean up ...
    wasmer_imports_destroy(imports);
    wasmer_store_destroy(store);
    wasmer_engine_destroy(engine);

    return 0;
}

            

              
                Copy
              
            
          

Modulo WASM (compilato da C/Rust con una funzione chiamata `log`):

            
// Example in C:
extern void log(int message_ptr, int message_len);

void my_wasm_function() {
    const char* message = "This is from WASM!";
    // Need to write message to WASM linear memory and get its pointer/length
    // For simplicity, assume memory management is handled.
    int msg_ptr = /* get pointer to message in WASM memory */;
    int msg_len = /* get length of message */;
    log(msg_ptr, msg_len);
}

            

              
                Copy
              
            
          

Spiegazione:

• L'host C++ definisce una funzione nativa (`my_host_log`) che sarà chiamabile da WASM.
• Definisce la firma attesa di questa funzione host.
• Viene creata una `wasmer_func_t` dalla funzione nativa e dalla sua firma.
• Questa `wasmer_func_t` viene aggiunta a un oggetto di importazioni sotto un nome di modulo specifico (es. "env") e un nome di funzione (es. "log").
• Quando il modulo WASM viene istanziato, importa la funzione "log" di "env".
• Quando il codice WASM chiama `log`, il runtime Wasmer la inoltra alla funzione C++ `my_host_log`, passando attentamente i puntatori alla memoria e le lunghezze.

Sfide e Migliori Pratiche

Sebbene i binding host offrano un potere immenso, ci sono sfide da considerare:

Sfide:

• Complessità del Marshalling dei Dati: Passare strutture dati complesse (stringhe, array, oggetti, tipi personalizzati) tra WASM e l'host può essere intricato, specialmente nella gestione della proprietà e della durata della memoria.
• Overhead Prestazionale: Chiamate frequenti o inefficienti tra WASM e l'host possono introdurre colli di bottiglia nelle prestazioni a causa del cambio di contesto e della copia dei dati.
• Strumenti e Debugging: Il debugging delle interazioni tra WASM e l'host può essere più impegnativo del debugging all'interno di un ambiente a linguaggio singolo.
• Stabilità delle API: Sebbene WebAssembly sia stabile, i meccanismi di binding host e le API specifiche del runtime possono evolvere, richiedendo potenzialmente aggiornamenti del codice. WASI mira a mitigare questo problema per le interfacce di sistema.
• Considerazioni sulla Sicurezza: Esporre troppe capacità dell'host o binding implementati in modo inadeguato può creare vulnerabilità di sicurezza.

Migliori Pratiche:

• Minimizzare le Chiamate Cross-Sandbox: Raggruppare le operazioni ove possibile. Invece di chiamare una funzione host per ogni singolo elemento in un grande set di dati, passare l'intero set di dati in una sola volta.
• Usare Strumenti Specifici del Runtime: Sfruttare strumenti come wasm-bindgen (per JavaScript), o le capacità di generazione di binding di runtime come Wasmtime e Wasmer per automatizzare il marshalling e ridurre il codice boilerplate.
• Privilegiare WASI per le Interfacce di Sistema: Quando si interagisce con funzionalità di sistema standard (I/O di file, networking), preferire le interfacce WASI per una migliore portabilità e standardizzazione.
• Tipizzazione Forte (Strong Typing): Assicurarsi che le firme delle funzioni tra WASM e l'host corrispondano precisamente. Utilizzare binding type-safe generati ogni volta che è possibile.
• Gestione Accurata della Memoria: Comprendere come funziona la memoria lineare di WASM. Quando si passano dati, assicurarsi che siano correttamente copiati o condivisi, ed evitare puntatori penzolanti o accessi fuori dai limiti.
• Isolare il Codice Non Attendibile: Se si eseguono moduli WASM non attendibili, assicurarsi che vengano loro concessi solo i binding host minimi necessari e che vengano eseguiti in un ambiente strettamente controllato.
• Profiling delle Prestazioni: Eseguire il profiling della propria applicazione per identificare i punti critici nelle interazioni host-WASM e ottimizzare di conseguenza.

Il Futuro dei Binding Host WebAssembly

Il panorama di WebAssembly è in costante evoluzione. Diverse aree chiave stanno plasmando il futuro dei binding host:

• WebAssembly Component Model: Si tratta di uno sviluppo significativo che mira a fornire un modo più strutturato e standardizzato per i moduli WASM di interagire tra loro e con l'host. Introduce concetti come interfacce e componenti, rendendo i binding più dichiarativi e robusti. Questo modello è progettato per essere agnostico rispetto al linguaggio e funzionare su diversi runtime.
• Evoluzione di WASI: WASI continua a maturare, con proposte per nuove capacità e perfezionamenti a quelle esistenti. Ciò standardizzerà ulteriormente le interazioni di sistema, rendendo WASM ancora più versatile per gli ambienti non-browser.
• Miglioramento degli Strumenti: Aspettatevi continui progressi negli strumenti per la generazione di binding, il debugging di applicazioni WASM e la gestione delle dipendenze tra ambienti WASM e host.
• WASM come Sistema di Plugin Universale: La combinazione di sandboxing, portabilità e capacità di binding host di WASM lo posiziona come una soluzione ideale per la creazione di applicazioni estensibili, consentendo agli sviluppatori di aggiungere facilmente nuove funzionalità o integrare logica di terze parti.

Conclusione

I binding host WebAssembly sono il cardine per sbloccare il pieno potenziale di WebAssembly oltre il suo contesto iniziale del browser. Essi consentono una comunicazione e uno scambio di dati trasparenti tra i moduli WASM e i loro ambienti host, facilitando potenti integrazioni su diverse piattaforme e linguaggi. Che stiate sviluppando per il web, applicazioni server-side, sistemi embedded o edge computing, comprendere e utilizzare efficacemente i binding host è la chiave per costruire applicazioni performanti, sicure e portabili.

Adottando le migliori pratiche, sfruttando strumenti moderni e tenendo d'occhio gli standard emergenti come il Component Model e WASI, gli sviluppatori possono sfruttare la potenza di WebAssembly per creare la prossima generazione di software, consentendo veramente al codice di funzionare ovunque, in modo sicuro ed efficiente.

Pronto a integrare WebAssembly nei tuoi progetti? Inizia oggi a esplorare le capacità dei binding host del tuo runtime e linguaggio scelti!